systemd: add xen systemd service and module files

systemd: add xen systemd service and module files

This adds the systemd xen service / module files and integrates
support into the build system.

This goes in with AX_AVAILABLE_SYSTEMD() which will enable
systemd if development libraries have been found on your
build system. If you don't have systemd on target systems
for binaries built with systemd then the binary will not
work, you must explicitly disable systemd support if you
do not want to build systemd support.

When systemd libraries are present only systems that
have booted into systemd go through the systemd initialization,
otherwise the SysVinit is used.

These are originally based on the Fedora systemd files.

Changes made from Fedora's systemd files:

  * split sockets into two files to claim different permissions
  * Use /bin/sh -c exec to for a simple launcher implementation
  * enables systemd socket activation for C xenstored and Ocaml
    oxenstored
  * use sd_notify(), so change the service to Type=notify, because of
    this we remove the PIDFile specification as we don't care for it, and let
    systemd do its magic for us, this also means we don't have to fork
    so we use --no-fork with systemd
  * defines a modules-load.d, its original source file will be shared
    between systemd and old init systems
  * simplify service files with ConditionVirtualization=xen which uses
    the built in systemd virtualization backend detection, these
    service files will not be available to start on systems that do not
    boot with xen as a hypervisor
  * use autoconf to replace @variable@ paths for us which piggy
    backs on top of the latest autoconf changes to xen
  * removes oxenstored service file in favor of a system variable which
    controls which which xentored to use at run time, we avoid multiple
    service files this way.
  * simplifies startup to not require polling on the sockets
    as initial socket management is handled by systemd, we just
    take on the socket later once anything pokes at it, a simple nc -U
    (as root) on any of the sockets files can activate the service for example.
    Anything queued up will be sent to us once we start. Socket activation
    should in theory also let us dynamically switch between xenstores but more
    importantly we could upgrade xenstored while keeping all active
    socket communication queued up, but in order to take advantage of
    this we eventually would need to remove the requirement of not being
    able to bring down the xenstored. Even though active sockets are
    supported since most libxl communication doesn't triggger a check
    on the unix socket first administrators are encouraged to enable
    the xenstored.service to triggger an initialization of the xenstored
    upon bring up. Some systems also never use unix sockets for
    communication with the xenstored and as such active sockets will
    not be used there.
  * allow for xenstored configuration through *either* of these
    configuration files:
	- /etc/sysconfig/xenstored
	- /etc/default/xenstored
    The /etc/default/xenstored will let debian based systems do
    the same, while SUSE/OpenSUSE/Fedora/RedHat can keep on chugging
    with sysconfig. We leave these files all commented out by default
    though given that for systemd we want to encourage not using them.
  * ensures we create the run directory as most systems will likely
    be using a tmpfs for run dirs for the pid files
  * Some systems define the selinux context in the systemd Option for the
    /var/lib/xenstored tmpfs:
	Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
    For the upstream version we remove that and let systems specify the
    context on their system /etc/default/xenstored or /etc/sysconfig/xenstored
    $XENSTORED_MOUNT_CTX variable, with a default to none.
  * takes advantage of the shared xendomains helper for the xendomains
    service
  * Add the new dom0 that gets kicked off for disk backend access into
    its own systemd service associated to xen

We end up with these systemd files:

General requirements:

  * proc-xen.mount
  * var-lib-xenstored.mount

xenstored:

  * xenstored.service
  * xenstored.socket
  * xenstored_ro.socket
  * xenconsoled.service
  * xen-qemu-dom0-disk-backend.service.in

Optional:

  * xendomains.service
  * xen-watchdog.service

As for integration with xen, we house keep all the systemd files
under a new directory tools/hotplug/Linux/systemd/ and will be targeted
by default when building on Linux systems if systemd development
libraries are present at build time.

The systemd files will be sanitized for meta @VARIABLES@ upon
configuration and installed upon the install target. Systems that
do not use systemd can still get systemd service unit files installed
if the build system enabled systemd support, this however does not
mandate a requirement of having systemd libraries present. Old init
scripts are always installed.

If you don't specify a prefix you will end up with the services
files under /usr/local/lib/systemd/system/ by default, and systemd
modules-load.d conf files under /usr/local/lib/modules-load.d/ which
systemd does look for (although it seems this is not documented).

Distributions are expected to provide their /usr/ prefix to end up in
the more generic location upon distribution install at
/usr/lib/systemd/system/ and /usr/lib/modules-load.d/ respectively.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Rękorajski <baggins@pld-linux.org>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Jacek Konieczny <jajcus@jajcus.net>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]